1. Field of the Invention
This invention relates generally to the field of computer and network bus architectures. More particularly, the invention relates to an improved point-to-point link topology for transferring data within computer and/or network I/O systems.
2. Description of the Related Art
In the context of computer systems and networks, buses are well-defined physical interfaces between system components. Sometimes the interface is used exclusively between internal components (referred to as a xe2x80x9cnon-exposed interfacexe2x80x9d), while in other cases the interface is exposed in the form of connectors or bus slots to provide some degree of modularity. Modularity is the ability to modify the system by adding/removing modules or functions (e.g., adding/removing I/O cards).
Beyond the physical characteristics (i.e., the electrical and mechanical characteristics), a bus may also be defined based on the specific manner in which it transmits data to and from components. In other words, a bus may define the behavior of the interfacing components at higher levels of abstraction than a mere physical connection. This level of abstraction varies widely based on the particular bus involved (e.g., some buses are defined by highly specific communication protocols, transactions, associated memory spaces . . . etc).
A very popular model for computer system buses has been the broadcast multi-point bus. This model is based on the principle that every component on the bus can hear every other component. It has traditionally been implemented as a xe2x80x9cpassivexe2x80x9d bus (i.e., the bus itself is a set of passive electrical traces, and only the interfacing components are electrically active). Typically, only one component on a broadcast bus may transmit data at any given time. As such, when a particular component needs to transmit/receive data over the bus, it must send a request to use the bus to some type of bus arbitration mechanism. When/if the bus is available, the arbitration mechanism will temporarily assign control of the bus to the requesting component. One exemplary bus arbitration configuration is referred to as a xe2x80x9cmulti-master broadcast bus.xe2x80x9d
Some well known examples of broadcast multi-point buses used in personal computers (xe2x80x9cPC""sxe2x80x9d) today include the Industry Standard Architecture (hereinafter xe2x80x9cISAxe2x80x9d) bus, the Extended ISA (hereinafter xe2x80x9cEISAxe2x80x9d) bus and the Peripheral Component Interconnect (hereinafter xe2x80x9cPCIxe2x80x9d) bus. One such configuration is illustrated in FIG. 1 which includes dual CPUs 160 and 161 that communicate over a system bus 150; dual I/O controllers 120 and 121 that communicate over an I/O bus 110; and a memory controller 130 which provides access to a system memory 140 for the CPUs 160 and 161 as well as for the I/O controllers 120 and 121 (i.e., via I/O bridge 125). I/O controllers 120 and 121 may reside on two I/O cards which physically interface with I/O bus 110 via two separate I/O bus slots.
As stated above, only one I/O controller may transmit data across I/O bus 110 at any given time. Thus, for example, if I/O controller 120 is disposed on a modem attempting to write data to a specified location in system memory 140, it may transmit data across I/O bus 110 only if the bus is currently available (e.g., only if no other controller is currently transmitting data over the bus). If, however, another I/O controllerxe2x80x94e.g., I/O controller 121xe2x80x94is using the I/O bus 110, then I/O controller 120 will make a request to use I/O bus 110 (via the particular bus arbitration mechanism in place). Once I/O controller 121 (and/or any other controller) has relinquished control of the bus, I/O controller 120 may then be granted access to I/O bus 110 and may subsequently write/read its data to/from I/O bus 110 (i.e., via I/O bridge 125 and memory controller 130).
There are significant problems associated with the foregoing broadcast multi-point I/O bus configuration. First and foremost, the data transfer rate of these prior art I/O systems has not kept pace with the vast improvements in CPU performance over the past several years. One obvious reason for this disparity is that only a single I/O controller may transmit data over the I/O bus at any given time. Accordingly, referring again to the above example, CPU 160 may be forced to wait for data to be transmitted from I/O controller 120 to system memory 140 before it can access the data or transmit/receive data over I/O bus 110. Computing performance may be severely degraded if I/O controller 120 and/or CPUs 160, 161 are forced to wait for a significant period of time before I/O bus 110 is released. For these reasons, the current broadcast multi-port I/O bus system represents a significant bottleneck to current system performance. Moreover, due to basic transmission line phenomena it is hard to cope with these issues using passive buses. Specifically, phenomena such as transmission line propagation time, skews, reflections, and intersymbol interference do not scale well with semiconductor process shrinks.
Another significant problem with the current I/O bus configuration is that both hot-swapping of bus components and I/O bus fault detection are unreasonably difficult. Hot-swap refers to the ability to remove components while the I/O system is active. While it is possible to execute a planned shutdown to replace a component on the current shared bus configuration, problems arise when a bus component is unexpectedly removed and/or shut down. This is primarily due to the fact that one I/O bus is shared by a number of different components (i.e., there is no way to isolate one portion of the bus). In addition, if the I/O bus is affected by a bus fault all of the components on the I/O bus may likewise be affected.
Finally, scalability is another problem associated with today""s I/O bus system, particularly with respect to server configurations. Bus performance simply does not scale well under today""s I/O usage models. Servers are generally purchased with the intent to expand as necessary to meet future component demand requirements. Once all the slots on today""s I/O bus are occupied, however, there can be little room for additional peripheral expansion.
It should be noted that broadcast buses are not restricted to the passive type described above. For example, they may be extended to be active star/tree configurations (e.g., using bus bridges), such as the Peripheral Component Interface (xe2x80x9cPCIxe2x80x9d) bus. Moreover, prior art relevant to the present application may include systems that are not strictly computers such as, for example, packet processing systems (e.g., those which use switches, routers . . . etc). Unlike computers, these types of systems do not implement memory controllers. Rather, they implement peer to peer packet communication across a network/bus.
For at least the foregoing reasons, an improved I/O system and apparatus is needed.
An apparatus is described comprising: a switch for providing a plurality of communication channels between a plurality of nodes; and a crossbar switch communicatively coupled between the switch and the nodes for allocating one or more of a plurality of links to each of the nodes.
Additionally, in a system including a switch for providing a plurality of communication channels between a plurality of nodes, a method is disclosed, comprising the steps of: determining bandwidth requirements of each node in the system; and allocating links to the nodes based on the bandwidth requirements.